One of the important frustrations of Internet users today is the need to manage different Internet identities for different online services, which in practice means remembering many different usernames, passwords and pin codes. The increasing number of applications and services available from both fixed and mobile devices demands a solution to manage all this sensitive information.
There are identity solutions and frameworks that deal with Identity exchange in Internet as OpenID, CardSpace, .NET Passport, Sibboleth and Liberty Alliance tools. All of these can only be used with web sites and online services that are compatible with these systems. They are complex tools which are described below in detail, and are not designed to use with a mobile handset.
There are two approaches to improving Internet identity management: single sign on (SSO) systems and identity meta-systems.
A single sign on system provides users with a single Internet identity that offers access to multiple web sites and online services. An identity meta-system lets a user manage his multiple existing Internet identities, and select the appropriate identity according to the web site or service requested. Shibboleth, OpenID, Liberty and .NET Password are single sign on systems, whereas Windows CardSpace is an identity meta-system.
Shibboleth is an open-source single sign on system based on the Security Assertion Markup Language (SAML), a standard which describes an XML format and protocol for exchanging authentication and authorization assertions between servers. FIG. 1 shows how Shibboleth works, the Shibboleth information flow.
The Shibboleth sign-in procedure consists of the following steps:    S1. The user accesses a protected resource (called the Service Provider), and requests a web page.    S2. The Service Provider redirects the user to the Where Are You From (WAYF) service, so that he can select his home organisation (called the Identity Provider).    S3. The WAYF service redirects the user to his Identity Provider.    S4. The user authenticates himself, by whatever authentication procedure his Identity Provider requires.    S5. After successful authentication, the Identity Provider generates a one-time handle or session identifier for this session, and redirects the user to the Service Provider.    S6. The resource can use the handle to request attribute information for this user from the Identity Provider (optional).    S7. The Identity Provider provides or denies the requested attribute information.    S8. Based on the authentication information and attribute information made available, the Service Provider gives or denies the user access to the requested resource.
At present, Shibboleth is mostly used among academic institutions and research centres. Note that in Shibboleth, a user has to belong to an organisation which can assert his identity. One of the features of Shibboleth is that it allows stronger or weaker authentication, depending on the attributes exchanged between Service Provider and Identity Provider.
OpenID is a single sign on system that allows internet users to access websites with one single “OpenID”, OpenID is an open distributed system the use of which is free of charge. In principle any user or organization can become an OpenID Provider, and a user can choose any OpenID Provider that suits his or her needs. In fact, a user can very easily change OpenID Providers without loosing his or her OpenID.
FIG. 2 shows how OpenID works. The OpenID sign-in procedure consists of the following steps:    S1′. The user accesses an OpenID enabled website (called the Consumer in OpenID terminology), and the site provides a form requesting the user's OpenID identity.    S2′. The user enters his OpenID, for example johan.vodafone-id.com and submits the form to the OpenID Consumer.    S3′. The OpenID Consumer converts the OpenID (e.g. johan.vodafone-id.com) to the URI normal form (e.g. http://johan.vodafone-id.com) and does a HTTP GET to this URI.    S4′. The site returns a HTML document from which the Consumer can derive the location of the OpenID Provider (note that in this example they are the same).    S5′. The Consumer sends a HTTP POST to the OpenID Provider with an associate request. This establishes a shared secret between the Provider and Consumer, using the Diffie-Hellman algorithm.    S6′. The OpenID Provider returns an association handle (with a set expiration date and time) for use in future requests.    S7′. The OpenID Consumer now redirects the user to the OpenID Provider for login.    S8′. The user authenticates his identity with the OpenID Provider.    S9′. The OpenID Provider redirects the user back to the Consumer website, providing the necessary authentication verification in a querystring.
Although the OpenID information flow resembles that of Shibboleth, there are two important differences:    In OpenID, the user asserts his own identity while in Shibboleth, it is the user's organization (the Identity Provider) that “owns” the user's identity.    Open IDs are persistent and independent of the OpenID Provider a user chooses to register with. In Shibboleth, a user's identity is linked to his organization (acting as Identity Provider).
This means that OpenID has certain advantages in terms of openness and universality. Although the use of single sign on in Internet is not yet widespread, it appears as though OpenID is quickly gaining acceptance. Some sites that accept OpenID, or will do so in the near future, include AOL, Yahoo, Flickr, Blogger, Orange, Sun, Novell, and Oxfam.
Critics argue that the current implementation of OpenID has security flaws. OpenID does offer protection from identity spoofing and man-in-the-middle attacks, since the query string used for logging a user into the Consumer website is signed with the shared secret between Consumer and Provider. However, it remains possible for a malignant Consumer to spoof OpenID provider's authentication pages, and thus obtain a user's OpenID password and credentials.
The user can protect himself against this type of attacks by registering with secure OpenID provider which uses trustworthy certificates to accredit its identity. Unfortunately however, the average user is generally not aware of how certificates work and how to trust (or mistrust) them.
Liberty Alliance is a complete identity management framework that offers not only single sign on but also single sign-out, identity federation and web services specifications for building interoperable identity applications. Like Shibboleth and OpenID, the Liberty protocols are also based on SAML.
As FIG. 3 shows, the Liberty single sign on procedure is similar to that of Shibboleth and OpenID. The Liberty sign-in procedure consists of the following steps:                S1*. The user accesses the web site of a Service Provider that is Liberty enabled.        S2*. The Service Provider determines the user's Identity Provider from the HTTP request.        S3* and S4*. The Service Provider redirects the user to the Identity Provider. The Identity Provider authenticates the user.        S6* and S7*. The Identity Provider redirects the user to the Service Provider with the assertion of his or her identity.        S8* and S9*. The Service Provider and Identity Provider exchange handles.        S10*. The Service Provider asserts the process.        S11*. The Service Provider provides access to the user.        
Liberty Alliance is a large scale industry initiative dating back to 1999. Liberty Alliance members include IT and telecommunications vendors, banks and credit card companies, and telecommunications operators. Vodafone, France Télécom and NTT DoCoMo are Liberty Alliance members, among many others.
In spite of its wide industry and political backing, Liberty use is still not widespread on the Internet. Liberty appears to be accepted mostly by large organizations and governmental bodies, but has not penetrated into mid-size and smaller on-line services, which make up most of the Internet today. Critics of Liberty Alliance argue that this is due to the complexity of the Liberty architecture and federation mechanisms. While Liberty does provide a complete framework for identity management, this appears to be overkill for most “common” websites wishing to offer single sign on.
“.NET Passport” is Microsoft's single sign on system. NET Passport issues the user with a “Windows Live Id” which can be used in all Microsoft services as well as on some other sites. Like OpenID, .NET Passport only authenticates user identities, it does not authorize user access to web pages.
At present, .NET Passport and Windows Live Ids appear to be used mostly for Microsoft related services. Though some other web sites offer .NET Passport based authentication, the use of Windows Live Id is not widespread beyond Microsoft web sites and online services.
The way .NET Passport works is similar to how OpenID works, as illustrated in FIG. 4: when the user signs into a page that is Passport enabled, his browser is redirected to a .NET Passport site which will authenticate the user. If the user successfully authenticates, the .NET Passport site sends the authentication information back to the user's browser in the form of an encrypted query string and cookies; the user's browser then forwards this information to the original site for authorization. As show in FIG. 4, the .NET Passport procedure consists of the following steps:                S1″. User's browser sends initial page request to the participating site.        S2″. Redirect for authentication.        S3″. User's browser send a request for sign-in page to the passport site.        S4″. The user's browser obtains the sign-in page from the passport site.        S5″. Send user credentials to the passport site.        S6″. Update passport.com cookies of the user's browser and redirect to the participating site.        S7″. Send encrypted authentication query string to the participating site.        S8″. The user's browser receives site cookies and requested page from the participating site.        
.NET Password differs from OpenID in the way that handles to the requested page are managed. In .NET there is mostly one identity provider (Microsoft), so that it is unnecessary to establish a shared secret and associate handles as part of the sign-in flow. In .NET Passport all communication goes through the user's browser.
But the most important difference lies in the fact that OpenID is an open system that supports distributed identity management, whereas Windows Live Ids are principally managed by Microsoft.
Most identity meta-systems, and most notably Windows CardSpace, are based on variations of the info card concept. An info card is a container for an Internet user's identity, issued by a trusted party, which can be presented to a web site or online service that requests authentication. It is graphically represented on the user's computer as an Identity card. An info card can be configured by the user himself, but it can also provide a digital certificate issued by one of the trusted parties he or she has a relationship with.
Note that the info card only serves as an identity selector, it is not a single sign on system like OpenID, Liberty or .NET Passport in itself.
The present invention solves the commented problems on the above systems by providing a system and method which enables the use of a mobile handset to easily log-in in Internet website and not to remember a lot of username-password tuples. The objective of the present system, Dial Your Identity (DYI onwards), is to allow users to manage and use the identities they need in their regular navigation in the Internet with their mobile phones extending the use of the mobile phone to provide services beyond basic communications. Therefore, the system proposed in the present invention provides a user a simple way of managing and using his Internet Identities (username-password pairs) using their mobile handset, offering a very easy way to log-in Internet web sites.